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PREFACE 


To  examine  specific  Automated  Guideway  Transit  (AGT)  developments  and 
concepts  and  to  build  a data  base  for  future  decision-making,  the  Urban  Mass 
Transportation  Administration  (UMTA)  undertook  a program  of  studies  and 
technology  investigations  called  the  UMTA  Automated  Guideway  Transit  Tech- 
nology (AGTT)  program.  The  objectives  of  one  segment  of  the  AGTT  program, 
the  System  Operations  Studies  (SOS),  was  to  develop  models  for  the  analysis 
of  system  operations,  to  evaluate  AGT  system  performance  and  cost,  and  to 
establish  guidelines  for  the  design  and  operation  of  AGT  system.  This 

program  resulted  in  a comprehensive  set  of  AGT  system  planning  and  system 
development  models.  In  order  to  maximize  the  benefits  resulting  from  the 
availability  of  these  models,  the  model  research,  development  and  analysis 
activity  was  continued  by  the  issuance  of  Contract  DOT-TSC-1783  in  September 
1979  for  the  Extended  System  Operations  Studies  (XSOS)  to  GM  Transportation 
Systems  Center. 

To  achieve  the  objectives  of  the  Extended  System  Operations  Studies 
project,  the  model  research  and  development  activity  was  continued  through 
the  implementation  of  software  improvements  and  design  changes  to  the 
models.  Additional  model  validation  activities  were  accomplished  and  an 
analysis  procedure  which  is  supported  by  the  SOS  models  was  developed. 
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EXECUTIVE  SUMMARY 


A set  of  computer  models  was  developed  during  the  System  Operations 
Studies  (SOS)  project  for  the  analysis  of  guideway  transit  system  operations. 

In  order  to  maximize  the  benefits  resulting  from  the  availability  of  these 
models,  the  model  research,  development  and  analysis  activities  were  continued 
by  the  issuance  of  Contract  DOT-TSC-1783  in  September  1979  for  the  Extended 
System  Operations  Studies  (XSOS)  to  GM  Transportation  Systems  Center. 

The  accomplishments  under  the  Extended  System  Operations  Studies  contract 
are  summarized  in  this  report.  The  three  primary  areas  covered  are:  the 

development  of  a set  of  analysis  procedures  which  are  supported  by  the  computer 
models  developed  during  the  SOS  Project,  the  software  changes  made  to  the 
Discrete  Event  Simulation  Model  (DESM)  to  expand  and  improve  its  capability  to 
model  guideway  transit  systems,  and  the  validation  of  the  ability  of  the  DESM 
to  accurately  model  vehicle  merges  and  the  generality  of  modeling  custom  designed 
dispatching  algorithm. 

Also  included  in  this  report  is  a description  of  three  system  level  models 
and  their  possible  application  to  the  analysis  of  conventional  transit. 


1.0  INTRODUCTION 


This  final  report  summarizes  and  documents  the  work  accomplished  by 
GM-TSC  in  the  fulfillment  of  the  Extended  System  Operations  Studies  con- 
tract. Also  provided  in  this  document,  is  an  overview  of  the  capabilities 
of  system  level  models  developed  during  the  SOS  contract.  In  the  case  of 
the  Discrete  Event  Simulation  Model,  the  capabilities  were  subsequently 
augmented  with  additional  modeling  features.  This  effort  was  accomplished 
during  the  XSOS  contract. 

Section  2.0  of  this  reports  provides  a description  of  the  purpose, 
inputs,  outputs  and  methodology  that  went  into  the  basic  design  of  the  SOS 
model s. 

Section  3.0  discusses  the  design  modifications  that  were  made  to  the 
Discrete  Event  Simulation  Model.  These  design  modifications  constitute  one 
of  the  major  efforts  of  the  XSOS  contract.  Also  included  in  this  section, 
is  a summary  of  the  model  validation  work  that  was  accomplished  as  the 
second  major  effort  of  the  XSOS  contract. 

Section  4.0  describes  an  analysis  procedure  developed  under  the  XSOS 
contract,  which  is  generally  applicable  to  transportation  systems.  The 
analysis  procedure,  addresses  the  application  of  the  SOS  models  to  the 
analysis  process. 

Section  5.0  describes  the  previous  applications  of  the  SOS  models  to  the 
analysis  of  various  types  of  automated  transit  systems.  This  includes  the 
analysis  of  actual  as  well  as  synthesized  automated  transit  system  and  the 
application  of  the  models  during  the  preliminary  engineering  of  the  Detroit 
Downtown  People  Mover. 

Section  6.0  discusses  the  results  of  work  done  under  the  XSOS  contract 
in  evaluating  potential  applications  of  the  system  level  SOS  models  to 
conventional  transit  analysis. 
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Section  7.0  presents  a summary  of  the  accomplishments  during  the  XSOS 
contract  and  an  identification  of  the  deliverables  provided  in  fulfillment 
of  the  contract. 
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2.0  SOS  MODEL  CAPABILITIES 


2.1  MODEL  TYPES 


The  set  of  SOS  models  enables  the  evaluation  of  the  performance,  cost, 
and  availability  characteristics  of  AGT  deployments.  The  evaluation  results 
provide  a basis  for  making  reasonable,  low-risk  decisions  in  the  selection 
or  development  of  new  Automated  Guideway  Transit  Systems.  The  SOS  models 
have  been  designed  to  analyze  a wide  range  of  alternative  AGT  system  designs 
and  application  scenarios. 

The  computer  models  developed  for  AGTT-SOS  fall  into  three  basic 
categories; 


2.1.1  SYSTEM  LEVEL  MODELS 

Discrete  Event  Simulation  Model  (DESM)  - A detailed  simulation  of  the 
movements  of  individual  vehicles  and  passengers  throughout  an  AGT  deployment 
using  discrete  event  simulation  techniques. 

Downtown  People  Mover  Simulation  (DPMS)  - A modified  version  of  the  DESM 
providing  a direct  interface  with  UTPS. 

System  Planning  Model  (SPM)  - A simulation  of  AGT  system  operations  in 
terms  of  average  flow  rates  of  vehicles  and  passengers. 

System  Availability  Model  (SAfi)  - An  analytic  model  using  equipment 
failure  rates  and  simulated  operations  data  to  evaluate  system  availability. 

System  Cost  Model  (SCM)  - An  analytic  model  using  unit  costs,  deployment 
configuration,  simulated  operations  data,  and  economic  factors  to  calculate 
capital,  operating,  and  life  cycle  costs. 
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2.1.2  SUBSYSTEM  LEVEL  MODELS 


Detailed  Station  Model  (DSM)  - A detailed  simulation  of  the  movement  of 
vehicles  and  passengers  in  a station. 

Detailed  Operational  Control  Model  (DOCM)  - A detailed  simulation  of 
vehicle  movements  on  a link,  and  through  a merge  or  intersection. 

Feeder  System  Model  (FSM)  - A simplified  model  of  feeder  system  opera- 
tion used  to  estimate  the  trips  served  by  an  ACT  deployment  out  of  a total 
set  of  transit  oriented  trips  in  an  area. 


2.1.3  ANALYSIS  SUPPORT  MODELS 

A set  of  support  programs  provide  the  capability  to  build  networks, 
display  dynamic  vehicle  motion,  queue  lengths  and  link  loading,  generate 
deterministic  demand  profiles,  compare  summary  statistics,  and  preprocess 
structured  Fortran. 


2.2  MODEL  OVERVIEW 


The  overviews  presented  here  are  of  those  system  level  models  most 
applicable  to  the  analysis  of  conventional  transit  systems,  that  is,  the 
Discrete  Event  Simulation  Model  (DESM),  the  System  Availability  Model  (SAM), 
and  the  System  Cost  Model  (SCM).  Descriptions  of  the  capabilities  of  the 
subsystem  level  models  and  the  analysis  support  models  are  contained  in  the 
System  Operations  Studies  for  Automated  Guideway  Transit  Systems  Final 
Report. 


2.2.1  DISCRETE  EVENT  SIMULATION  MODEL  (DESM) 

2.2.1 .1  Purpose 

The  DESM  is  a general  purpose  model  designed  to  simulate: 
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The  operation  of  an  AGT  system  deployment  over  a complete  network 
of  guideway  links  and  stations  within  a given  time  domain 

The  effects  of  various  operational  strategies  and  service  policy 
options  on  overall  system  performance 

Time  varying  demand  situations 

The  interaction  effects  of  vehicles  and  passengers  competing  for 
system  resources. 


2. 2. 1.2  Major  Inputs 


The  major  inputs  are: 


Network  definition  data  which  can  be  output  from  an  analysis 
support  model,  or  user  created.  The  network  data  contains  link 
node  numbers,  station  entry  indicators  and  link  length  for  each 
guideway  link  in  the  network. 

Station-to-station  demand  which  can  be  output  from  the  FSM,  or  user 
created.  The  demand  data  is  in  the  form  of  matrices  of  the  number 
of  passengers  traveling  from  origins  to  destinations,  the  asso- 
ciated time  period,  and  party  size  information. 

System  characteri sties  data  which  can  in  part  be  generated  by  an 
analysis  support  model  or  entirely  user  created.  The  system 
characteri sties  data  defines  the  system  to  be  simulated,  including, 
for  example,  the  nominal  speed  by  link  or  for  all  links,  walk  time 
for  transfers,  vehicle  board/deboard  times,  vehicle  capacity,  route 
assignments,  route  groups,  transfer  list,  station  type,  demand  stop 
indicator,  and  transfer  policy  selection. 

Runtime  data,  which  provides  the  user  with  simulation  control 
information  such  as,  demand  scaling  information,  nonzero-time  data 
for  failure/recovery  instructions,  and  output  requests. 


2. 2. 1.3  Major  Outputs 

The  major  outputs  include  the  following  major  types  of  data: 
Station  statistics 
Link  statistics 
Completed  trips  data 
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Vehicle  movement  data 


Station-to-station  travel  times 

Performance  summary  statistics  related  to  the  overall  system 
summaries  across  all  links,  stations,  and  routes  and  level  of 
service  measures  such  as  operations  including  average  travel  time 
per  completed  trip. 

In  addition  to  above  output  and  performance  summary  data,  the  DESN 
produces  many  other  reports  including  time  series  listings,  plots,  statis- 
tical summaries  and  histograms.  The  user  can  choose  from  a large  number  of 
measures:  resource  utilization  measures  such  as  fleet  size  and  total 

vehicle  hours,  performance  measures  such  as  average  trip  length  and  travel 
speed,  and  level  of  service  measures  such  as  average  wait  time  and  number  of 
transfers. 


2. 2. 1.4  Methodol ogy 

The  DESM  is  a general  purpose  event  model  designed  to  simulate  the 

operations  of  specified  AGT  systems  over  a complete  network.  The  transit 

systems  that  can  be  modeled  range  from  personal  rapid  transit  (PRT)  to 

automated  rail  transit  (ART)  using  networks  ranging  from  simple  shuttles  or 
loops  to  fully  connected  grids  with  guideway  link  combinations  which  include 
merges,  diverges,  and  grade-separated  intersections.  Station  representa- 
tions can  range  from  simple  to  complex  with  the  specific  event  processes 
being  defined  by  the  user. 

The  DESM  input  processor  transforms  the  network  definition,  trip  demand, 
and  level  of  service  data  input  by  the  user  into  an  internal  format  to 

provide  for  efficient  operation  of  the  model  processor.  The  model  processor 
contains  the  discrete  event  simulation  architecture  which  provides  the  time 
dependent  processing  of  all  functions  associated  with  trip  management  and 
station,  vehicle,  and  guideway  operations.  The  interaction  of  these  oper- 
ational character! sties  over  time  can  cause  queues  of  patrons  in  stations 
and  propagation  of  vehicle  congestion  on  the  guideway  and  in  stations.  The 
model  processor  accepts  asynchronous  commands  for  time  dependent  inputs  such 


2-4 


as  trip  requests,  fleet  size  changes,  and  introduction  of  failures  and  other 
external  stimuli.  The  model  processor  collects,  summarizes  and  fonnats 
statistical  data  at  user-specified  intervals  on  the  completed  events, 
current  operational  status,  and  queues  at  various  levels  of  detail  (system, 
station,  route,  link,  vehicle,  and  trip).  The  output  processor  is  used  to 
retrieve  the  statistical  output  from  the  model  processor.  The  output 
processor  also  calculates  simulation  period  performance  summary  measures  and 
both  prints  a report  and  writes  a file  for  later  comparison  with  the  results 
of  other  simulation  experiments. 

In  the  DESM,  a fleet  of  vehicles  circulates  over  a specified  network 
according  to  a selected  service  policy  and  provides  transportation  service 
on  an  individual  patron  basis.  Simulation  functions  associated  with  patrons 
include  arrival  at  a station,  assignment  of  a vehicle  to  service  the  trip 
request,  waiting  for  the  assigned  vehicle,  and  boarding  and  deboarding.  The 
travel  portion  of  the  patron  activity  is  modeled  in  conjunction  with  vehicle 
travel.  Vehicles  move  along  the  network  and  through  stations  according  to  a 
user-selected  system  management  strategy.  The  strategy  consists  of  indivi- 
dually selected  policies  for  type  of  service,  berth  assignment,  entrainment, 
empty  vehicle  allocation,  path  selection,  dispatch,  longitudinal  control, 
position  regulation,  and  merge  control.  Other  system  character! sties,  such 
as  vehicle  capacity,  nominal  speed,  and  headway,  are  also  included  factors 
in  the  simulation  of  system  performance. 

The  network  is  represented  in  the  DESM  by  a set  of  links  and  nodes.  A 
link  is  the  model  representation  of  a portion  of  the  network,  which  connects 
two  nodes  and  can  be  considered  uniform  in  its  character! Stic s. 

2.2.2  SYSTEM  AVAILABILITY  MODEL  (SAM) 


2. 2. 2.1  Purpose 


The  SAM  is  a system-level  model  which  provides  measures  of  vehicle  and 
passenger  availability.  Maintenance  and  standby  fleet  sizes  required  to 
support  the  operational  fleet  are  also  determined. 
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2. 2. 2. 2 


Main  Inputs 


The  major  inputs  are: 


Trip  Logs  which  are  produced  by  the  DESM  and  contain  for  a non- 
failure reference  case  and  for  each  failure  case,  information  on 
vehicle  and  passenger  travel  time  for  each  trip,  travel  distances, 
transfer  time,  and  number  of  passengers  for  each  trip. 

Failure  rate  and  maintenance  time  data  which  are  produced  by  the 
user,  such  as  failure  rates  by  subsystem,  the  average  time  to 
repair  and  to  service  a vehicle,  reliability,  region  characteris- 
tics, delay  thresholds  and  print  control  cards  for  selected  report 
generation . 


2. 2. 2. 3 Major  Outputs 


The  SAM  outputs  are: 

performance  summary  measures  which  include  standby,  maintenance, 
and  total  fleet  size,  number  of  service  bays  required,  and  vehicle 
and  passenger  availability. 

standard  reports  which  contain  failure  rates,  trips  delayed, 
vehicle  delay  times,  passenger  availability,  vehicle  availability 
and  maintenance  fleet  requirements. 


2. 2. 2. 4 Methodol ogy 


The  model  provides  the  capability  to  parametrical ly  evaluate  avail- 
ability measures  as  a function  of  network,  system  and  demand  characteristics 
by  considering  the  effects  of  failure  on  operation,  failure  response 
strategies,  hardware  reliability  and  maintainability,  and  level  of  parts 
quality  and  redundancy. 


Passenger  availability  is  defined  as  the  percent  of  total  completed 
trips  delayed  less  than  a specified  threshold.  Vehicle  availability  is 
defined  as  the  percent  of  total  vehicle  operating  hours  that  the  vehicles 
are  not  delayed  by  failures.  The  maintenance  fleet  is  the  expected  number 
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of  vehicles  in  maintenance  for  regular  service  or  failure  reasons.  The 
standby  fleet  is  the  number  of  vehicles  needed  to  assure  with  a certain 
probability  that  a vehicle  will  be  available  to  replace  a failed  vehicle. 

Passenger  availability  is  calculated  as  follows.  The  failure  rates  are 
specified  as  a function  of  subsystem  (vehicle,  station,  guideway,  control), 
cause  of  failure,  reliability  level  (off  the  shelf,  mil -standard,  redundant, 
etc.),  and  failure  type  (stoppage,  degraded  operation).  A standard  day's 
scenario  is  described  (for  several  distinct  demand  periods  and  regions)  to 
establish  the  values  of  the  causal  variables.  The  causal  variables  used  are 
vehicle  operating  hours,  number  of  passengers  through  stations,  system 
elapsed  time,  number  of  vehicles  through  stations,  vehicle  kilometers,  the 
number  of  stations,  and  guideway  kilometers.  The  number  of  passengers 
delayed  greater  than  specified  thresholds  is  determined  by  the  SAM  by 
comparing  DESM  trip  logs  generated  for  fail ure/recovery  situations  with 
those  of  the  nonfailed  case  for  the  specified  scenario.  The  trip  logs 
contain  trip  origin  and  destination,  departure  and  arrival  times,  number  of 
transfers,  and  the  number  of  people  traveling  together.  The  expected 
failures  for  the  scenario  are  determined  from  the  failure  rate  and  the 
causal  factor  values.  For  example,  the  number  of  failures  at  stations  is  a 
function  of  the  station  failure  rate,  the  passenger  flow  through  stations, 
system  elapsed  time,  the  number  of  stations,  and  the  vehicle  flow  through 
the  station.  The  expected  number  of  delays  above  a given  threshold  are 
calculated  by  multiplying  the  number  of  expected  failures  by  the  fraction  of 
passengers  delayed  above  the  threshold  for  those  types  of  failures.  Pas- 
senger availability  is  calculated  using  the  total  number  of  trips  and  the 
expected  number  of  passengers  delayed  above  the  specified  thresholds. 
Vehicle  availability  is  determined  without  regard  to  threshold,  but  rather 
considers  the  hours  of  delay  as  a consequence  of  failure  in  comparison  with 
non  failure  conditions. 

The  standby  fleet  size  is  determined  as  a probability  function.  This 
probability  is  a function  of  the  active  fleet  size,  the  vehicle  failure 
rate,  and  the  number  of  service  bays  and  their  service  rates.  A standby 
fleet  is  set  to  achieve  a specified  probability  that  the  standby  fleet  is 
adequate,  e.g.,  95  percent  that  a vehicle  will  be  available  when  required. 
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The  average  number  of  vehicles  in  maintenance  (the  maintenance  fleet)  is  the 
number  receiving  routine  servicing  plus  the  number  expected  to  be  in  main- 
tenance to  repair  failures. 

Up  to  five  alternative  reliability  levels  for  a given  system  can  be 
analyzed  in  a single  SAM  run.  In  addition  to  varying  the  reliability 
levels,  the  user  can  also  specify  up  to  ten  passenger  delay  thresholds. 
Each  delay  threshold  will  have  a direct  effect  on  passenger  availability  by 
varying  the  number  of  passengers  considered  by  the  model  to  be  significantly 
delayed. 


2.2.3  SYSTEM  COST  MODEL  (SCM) 


2. 2. 3.1  Purpose 

The  SCM  is  an  interpretive  program  that  determines  life  cycle  cost 
measures  taking  into  account  charges  for  interest,  replacement,  and  annual 
operation  and  maintenance. 


2. 2. 3. 2 Major  Inputs 

The  major  SCM  inputs  include: 


Data  equations  for  the  life  cycle  cost  process. 

Deployment  data  values  representing  the  cost  items  that  are  site 
specific.  These  include  guideway  data,  such  as  the  length  of 
elevated  single  lane  urban  guideway;  passenger  station  data,  such 
as  the  number  of  turnstiles  in  each  station;  support  facilities, 
such  as  central  control  buildings;  annual  vehicle  operations,  such 
as  number  of  passengers  and  vehicle  kilometers;  feeder  service 
data,  such  as  passengers  and  vehicle  kilometers;  and  inflation 
factors. 

System  data  which  includes  unit  costs  and  technology  items  which 
are  specific  to  system  type.  These  include  vehicle  and  guideway 
unit  costs  and  vehicle  propulsive  unit  energy. 
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Common  data  which  includes  costs  and  factors  general  to  all  systems 
and  deployments.  These  include  building  and  equipment  costs,  such 
as  cost  per  ticket  machine;  nonpropul  si ve  unit  energy  requirements, 
such  as  BTU/m^/yr  for  air  conditioning;  unit  pollution  data,  such 
as  grams  of  CO  per  kwH;  and  general  cost  factors,  such  as  percent 
of  total  vehicle  cost  for  spare  parts. 


2. 2. 3. 3 Major  Outputs 
The  SCM  outputs  are: 

The  performance  summary  measures  selected  by  the  user. 

Standard  reports  which  provide  information  on  land  utilization, 
energy  consumption,  pollution,  capital  costs  at  purchase,  cumu- 
lative capital  costs  to  date,  annualized  cost,  cumultive  amortized 
cost  to  date,  and  present  values. 

2 . 2. 3 . 4 Methodology 

The  SCM  has  a unique  architecture  for  cost  calculations.  It  consists 
of:  a general  purpose  processor  capable  of  performing  cost  modeling 

functions  using  a general  purpose  tree  data  structure,  and  a data  base 
element  (input)  which  contains  the  tree  and  tree  traversal  control  tables 
which  represent  the  equations  to  be  used.  Since  the  equations  can  be 
altered  as  a model  input,  several  cost  models  can  be  developed  by  the  user. 


The  SCM  calculates  the  cash  flow  process  for  financing  and  operating  an 
ACT  system.  The  SCM  calculates  the  life  cycle  cost  of  an  ACT  system  by 
computing  the  effects  of  capital,  operating,  and  maintenance  expenditures 
throughout  a specific  life  cycle  period.  Several  environmental  measures  are 
also  calculated  by  the  SCM  - specifically,  energy  consumption,  pollution, 
and  land  use  requirements.  The  SCM  has  been  constructed  so  that  the  feeder 
system  attributes  associated  with  an  ACT  system  can  be  included  in  the  life 
cycle  cost  analysis. 
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Estimated  data  for  input  items  can  be  varied  to  determine  their  effect 
on  the  transit  system's  life  cycle  cost.  For  example,  the  SCM  is  programmed 
so  that  vehicle  maintenance  cost  is  calculated  by  adding  a cost  per  vehicle 
kilometer  (for  preventive  maintenance),  and  a cost  per  failure  (for  failure 
maintenance)  to  determine  a total  vehicle  maintenance  cost.  The  number  of 
failures  per  vehicle  per  year  can  be  varied  resulting  in  a new  life  cycle 
cost  for  the  transit  system. 
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3.0  SOFTWARE  MODIFICATIONS 


The  two  areas  of  SOS  software  modifications  that  were  accomplished 
during  the  XSOS  contract  were  related  to  expanding  the  simulation  capa- 
bilities of  the  DESM.  The  modifications  were,  made  first  to  improve  the 
failure  management  modeling  features  of  the  DESM  to  reflect  the  failure 
response  strategies  that  would  be  likely  to  be  used  in  the  application  of 
AGT  systems  to  Downtown  People  Movers  and,  second  to  incorporate  a service 
policy  representati ve  of  that  employed  by  the  Morgantown  PRT  System. 


3.1  FAILURE  MANAGEMENT 


The  DPM  Failure  Management  Task  developed  the  functional  and  technical 
requirements  of  the  software  modifications  to  the  DESM  necessary  to  imple- 
ment an  enhanced  failure  management  modeling  capability.  This  included  the 
development  of  improved  scheduled  service  vehicle  spacing  algorithms  and 
schedule  service  active  fleet  size  management  modifications. 


3.1.1  SCHEDULED  SERVICE  VEHICLE  SPACING  ALGORITHMS 

Additional  scheduled  service  vehicle  spacing  algorithms  were  developed 
and  added  to  the  DESM/DPMS  in  order  to  more  effectively  model  the  "debunch- 
ing"  of  vehicles  in  congested  situations,  particularly  after  link  and/or 
vehicle  failures. 

In  the  original  version  of  the  DESM,  three  vehicle  spacing  algorithms  were 
implemented.  Those  are  described  below. 

The  first  method,  called  "fixed  schedule"  launches  each  vehicle  at  a 
time  determined  by  an  absolute  fixed  time  schedule  which  demands  each 
scheduled  launch  time  to  be  one  route  headway  after  the  previous  scheduled 
launch  time.  Vehicles  which  are  behind  schedule  are  scheduled  to  be 
launched  as  soon  as  they  are  ready  with  no  additional  delay.  After  a link 
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failure  occurs  and  bunching  of  vehicles  result,  this  algorithm  will, 
however,  perpetuate  the  bunching  by  launching  each  vehicle  immediately 
because  it  is  behind  the  absolute  fixed  time  schedule. 

The  second  method,  called  "midpoint  spacing"  also  schedules  vehicle 
launches  based  on  this  absolute  fixed  time  schedule.  However,  if  a vehicle 
is  ahead  of  schedule,  it  is  only  delayed  half  the  time  until  the  scheduled 
departure  time.  Again,  if  a vehicle  becomes  ready  for  launch  only  after  the 
scheduled  time,  it  is  launched  immediately;  thus,  perpetuating  any  bunching. 

The  third  method,  called  "immediate  launch",  is  invoked  by  the  code  when 
the  first  method  is  chosen  while  demand  stop  service  is  in  effect.  In  this 
case,  the  absolute  fixed  time  schedule  is  disregarded  and  each  vehicle 
launches  as  soon  as  it  becomes  ready.  Again,  this  will  not  result  in 
"debunching"  after  failure  congestion. 

The  two  new  algorithms  developed  as  a part  of  this  task  are  based  on 
relative  time  schedules  rather  than  the  absolute  time  schedules  used  above. 
With  these  algorithms,  if  a vehicle  falls  behind  schedule,  subsequent 
vehicles  will  be  delayed  in  order  to  maintain  a reasonable  spacing  of 
vehicles  on  the  route.  This  will  result  in  a lower  system  capacity  but  will 
give  a more  consistent  level  of  service  to  all  passengers. 

The  first  new  algorithm,  called  "Fixed  Interval  Dispatch",  causes  a 
vehicle  to  be  launched  no  earlier  than  one  route  headway  time  after  the 
previous  vehicle  on  the  route  was  actually  launched  from  the  station. 
Vehicles  ready  for  launch  after  the  fixed  interval  are  sent  immediately. 
This  algorithm  accomplishes  debunching  after  failure-caused  queue  formation 
at  the  first  down  stream  station  and  will  restore  even  route  spacing  within 
one  cycle  of  the  route  by  the  first  vehicle. 

The  second  new  algorithm,  called  "Midpoint  Interval  Dispatch",  causes  a 
vehicle  to  be  launched  halfway  between  the  time  it  is  ready  and  one  route 
headway  after  the  previous  vehicle  was  actually  launched.  This  algorithm 
causes  vehicles  to  be  launched  more  quickly  after  failure  congestion  than 
does  the  fixed  interval  case  but  will  not  restore  even  spacing  as  soon. 
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3.1.2  SCHEDULED  SERVICE  ACTIVE  FLEET  SIZE  MANAGEMENT  MODIFICATION 


In  the  original  design  of  the  DESM  and  DPMS,  the  modeling  of  active 
fleet  size  changes  when  the  scheduled  service  mode  was  used  did  not  re- 
present the  transition  period  from  one  fleet  deployment  to  another  with 

sufficient  fidelity  for  the  evaluation  of  some  operations. 

The  original  implementation  of  the  DESM  modeled  scheduled  service  active 
fleet  size  management  by  marking  all  vehicle  trains  on  all  routes  to  enter  a 
deboard  only  mode,  removing  vehicle  trains  from  the  simulation  when  they 

become  empty,  and  simultaneously  launching  an  entire  new  fleet  of  vehicles 
equally  spaced  on  the  routes  by  using  the  same  mechanism  as  used  in  launch- 
ing the  initial  fleet.  While  this  modeling  would  return  the  system  to  a 

steady-state  operation  after  approximately  one  route  cycle  of  the  longest 
route,  it  violated  many  practical  constraints  of  real  systems  such  as  the 

total  number  of  vehicles  available  and  provided  an  artifical  continuance  of 
service  capacity  during  the  transition  period. 

Because  it  was  desired  to  obtain  more  accurate  information  from  the 
DESM/DPMS  concerning  system  performance  during  transition  periods  as  well  as 
during  the  following  steady-state  period,  design  changes  were  made  to  the 

DESM  to  more  realistically  model  scheduled  service  active  fleet  size  man- 

agement (AFSM). 

The  active  fleet  size  management  algorithm  was  modified  to  model  the 
redeployment  of  the  vehicle  fleet  by  using  the  currently  active  fleet  (plus 
incremental  vehicles  if  the  total  active  fleet  size  increases)  while  re- 
taining all  of  the  modeling  capabilities  of  the  previous  implementation. 

The  following  specific  capabilities  were  identified  as  desirable: 

f Change  number  of  vehicles  traveling  on  a route 

• Change  vehicle  train  headway  on  a route 

• Change  train  consist  (number  of  vehicles  per  train)  on  a route 
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• Change  service  on  one,  some,  or  all  routes 

t Specify  either  number  of  vehicles  on  route  or  route  headway  separation 

• Recalculate  and  maintain  route  spacing  on  a route 

f Constrain  total  fleet  size 

• Place  unneeded  vehicles  into  a deboard  only  mode  so  that  they  become 
empty 

f Remove  unneeded  empty  vehicles  by  moving  them  through  the  network  to 
storage  areas 

f Dispatch  new  vehicle  trains  from  storage  through  the  network  to  their 
assigned  route 

f Use  station  maintenance  areas  for  train  re-consisting  operations 

• Model  the  transition  period  and  service  disruption  more  real i stical ly  . 

Two  major  areas  of  design  change  were  made  in  order  to  implement  the 
modified  scheduled  service  AFSM  algorithm.  First,  the  concept  of  main- 
tenance barns  v/as  developed.  One  or  more  stations  in  the  network  are 
labeled  as  maintenance  barns  by  a new  input  variables  SBARN.  These  main- 
tenance barns  require  a storage  link  to  be  defined  as  well  as  one  or  more 
connecting  links  into  and  out  of  the  storage  link.  The  model  Input  Pro- 
cessor (IP)  then  calculates  a designated  maintenance  barn  for  each  route  by 
an  algorithm  designed  to  pick  the  maintenance  barn  which  will  allow  reformed 
trains  to  reach  a station  stop  on  the  route  in  the  minimum  time.  Given  the 
maintenance  barn  for  each  route,  the  processor  also  chooses  a station  stop 
on  the  route  as  the  station  with  the  minimum  travel  time  to  the  maintenance 
barn  to  deboard  all  passengers  prior  to  sending  the  train  to  the  barn. 

The  second  major  design  change  was  the  development  of  the  concept  of 
redeploying  the  existing  fleet  to  accomplish  active  fleet  size  management 
rather  than  launching  an  entire  new  fleet.  Vehicles  from  the  existing  fleet 
can  be  reassigned  to  other  routes  and/or  reconsisted  into  trains  on  their 
own  route  in  order  to  provide  the  new  requested  level  of  service.  Reconsis- 
ting and  route  reassignments  are  accomplished  at  the  appropriate  maintenance 
barn.  In  addition,  the  user  may  specify  the  existence  of  transition 
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vehicles  for  each  route  which  are  initialized  and  ready  for  entrainment  at 
the  route's  barn  maintenance  area  at  the  time  of  the  AFSM  event.  Transition 
vehicles  may  only  be  specified  for  routes  which  are  changing  train  consist 
or  are  increasing  the  number  of  vehicles.  The  simulation  initializes 
sufficient  transition  vehicles  to  meet  the  system-wide  total  of  vehicles 
needed  if  the  user  does  not.  The  user,  however,  may  specify  more  transition 
vehicles  than  needed.  In  this  case  and  in  the  case  where  total  fleet  size 
decreases,  unneeded  vehicles  are  removed  from  the  simulation  at  the  main- 
tenance barn  storage  link. 

If  the  total  number  of  vehicles  on  a route  is  to  decrease,  some  trains 
on  the  route  are  marked  for  termination.  A train  terminates  at  its  first 
station  stop  if  it  is  needed  by  another  route.  In  this  case,  the  train 
deboards  all  of  its  passengers  and  is  sent  to  the  other  route's  maintenance 
barn.  All  passengers  who  deboard  prematurely  are  treated  as  transfers  and 
reboard  the  next  appropriate  train  to  reach  their  destination.  If  no  other 
route  needs  a vehicle,  the  vehicle  will  terminate  at  the  closest  station 
stop  to  its  route's  maintenance  barn.  Also,  if  the  train  consist  size  on  a 
route  changes,  all  trains  traveling  the  route  at  the  old  consist  size 
terminate  at  the  closest  station  stop  to  the  route's  maintenance  barn. 
Terminating  vehicles  are  then  sent  to  the  maintenance  barn  for  reconsisting 
and  relaunching  on  a route. 

When  vehicles  arrive  at  the  storage  link  of  the  maintenance  barn,  they 
are  considered  ready  for  reassignment.  The  vehicles  are  first  detrained  and 
then  the  existing  AFSM  situation  is  examined.  Vehicles  remain  assigned  to 
their  original  route  unless  they  are  no  longer  needed.  If  enough  vehicles 
are  available  and  assigned  to  a route,  a new  train  is  formed  and  scheduled 
to  move  out  of  the  storage  link  to  commence  travel  on  the  route.  The  new 
train  is  sent  to  the  closest  station  stop  first.  If  the  vehicle  is  not 

needed  by  its  current  route,  it  is  reassigned  to  another  route,  using  the 
same  maintenance  barn,  having  the  greatest  unsatisfied  need  for  additional 
vehicles.  If  this  reassignment  results  in  enough  vehicles  being  available, 
a new  train  is  formed  and  launched  on  the  other  route.  If  no  such  re- 
assignment is  possible,  then  the  vehicle  is  reassigned  to  another  route 
using  another  maintenance  barn  which  has  the  greatest  unsatisfied  need  for 
additional  vehicles  and  is  scheduled  to  travel  to  the  other  route's 
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maintenance  station.  If  no  other  routes  have  unsatisfied  needs  for 
additional  vehicles,  then  the  vehicle  is  removed  from  the  simulation. 


3.1.3  ENHANCED  FAILURE  MANAGEMENT  MODELING 

The  original  design  of  the  DESM  and  DPMS  includes  the  capability  to  model 
vehicle  failures  and  recoveries  and  degraded  vehicle  operation.  These  failed 
vehicle  occurrences  were  modeled  in  a set  pre-determined  manner.  The  modeling 
capabilities  of  the  DESM  and  DPMS  were  enhanced  by  increasing  the  failure 
modeling  detail  so  that  a variety  of  realistic  failure  management  strategies 
can  be  evaluated  in  terms  of  total  vehicle  and  passenger  delay. 

A summary  of  the  major  functional  requirements  of  the  enhanced  failure 
management  modeling  were: 

0 Provide  user  choice  of  recovery  strategies 

• Model  failed  vehicle  restart  by  three  methods 

- vehicle  can  be  restarted 

- vehicle  is  pushed  by  trailing  vehicle 

- vehicle  is  towed  by  service  vehicle 

0 Remove  failed  vehicle  from  service  to  maintenance  area  and  replace  by 

another  vehicle 

0 Deboard  passengers  from  failed  vehicles  as  transfers  to  reboard  other 

vehicles 

0 Provide  four  responses  for  nonfailed  vehicles 

- remain  in  revenue  service 

- continue  service  in  deboard-only  mode 

- deboard  all  passengers  and  circulate  empty 

- go  to  next  station  and  wait  for  failure  recovery 

0 Move  failed  vehicle  at  degraded  speed  to  maintenance  area 

0 Provide  measures  of  failure  response  effectiveness- 

The  implementation  of  the  enhanced  failure  management  functions, 
identified  above,  required  three  major  areas  of  design  change  in  the  DESM/ 
DPMS.  The  requirement  to  provide  the  user  a choice  of  responses  is  the 
first  major  design  change.  This  implies  new  input  variables  to  specify  and 
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remember  the  user's  choice,  processing  to  validate  and  report  the  choices, 
and  new  or  modified  code  to  carry  out  the  modeling  implied  by  the  choices. 
The  second  major  design  change  resulted  from  the  composition  of  the  enhanced 
responses.  The  new  responses  require  several  time  delays  (some  input  by  the 
user  and  others  calculated  by  the  model)  to  be  a part  of  the  recovery 
process  rather  than  the  previous  method  of  utilizing  a user-specified 
failure  time  and  a user-specified  recovery  time.  The  resulting  design  then 
required  that  the  response  choices  and  time  delays  be  remembered  for  future 
processing  rather  than  be  immediately  executed  as  before.  This  design 
resulted  in  new  variables  and  new  and  modified  code  segments. 

The  following  input  is  required  to  specify  the  failure,  the  response, 
the  associated  time  delays,  and  the  response  parameters  needed  by  the 
enhanced  failure  management  strategies: 

• Failure  Specification  Card 

- Time 

- Location 

- Type  of  Failure 

- Degradation  Factor 

- Delay  to  Detection 

- Recovery  Method 

- Delay  to  Restart 

- Delay  to  Replacement 

- Recalculate  Minimum  Path 

§ Other  Vehicle  Response  (By  Route) 

f Tow  Vehicle  Path 

• Tow  Vehicle  Speed  Degradation  Factor 

• Maintenance  Barn  Identification. 

Table  3-1  describes  the  steps  that  occur  in  the  three  restart  strat- 
egies, Table  3-2  describes  the  actions  taken  by  the  simulation  to  effect  the 
other  vehicle  responses.  These  can  be  specified  by  route  in  the  scheduled 
service  case.  The  default  specification  is  to  remain  in  revenue  service. 
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No  new  statistics  or  measures  were  created  as  a result  of  the  enhanced 
failure  modeling.  However,  additional  output  messages  were  generated  to 
document  the  time-series  nature  of  the  new  failure  responses.  One  or  two 
line  messages  are  reported  by  the  model  processor  as  each  failure  event 
occurs.  These  messages  include  vehicle  ID's,  link  numbers,  link  entry  or 
exit,  and  time  of  event  occurrence  for  the  various  events.  The  events 
include  vehicle  capture,  failure  detection,  vehicle  restart,  push  coupling 
begins,  tow  path  becomes  clear,  vehicle  reaches  maintenance  area,  replace- 
ment vehicle  available,  and  replacement  train  dispatched. 

These  new  messages  when  combined  with  the  existing  vehicle  and  passenger 
travel  statistics  provide  all  the  information  needed  for  analyzing  the 
effects  of  failure  conditions  and  alternative  failure  responses  in  a network 
scenari  o. 
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TABLE  3-1.  DEGRADED  VEHICLE  RESTART  STRATEGIES 


RESTART 


• Vehicle  scheduled  to  restart  at  user  input  time  delay  after  detection 


PUSH  BY  TRAIL  VEHICLE 

• At  detection  time,  if  vehicle  queued  behind  failure,  entrain  and 

schedule  restart  at  user  input  coupling  time  delay  after  detection 

f If  not,  whenever  next  vehicle  queues  behind  failure,  entrain  and 

schedule  restart  at  user  input  coupling  time  delay  after  current  time 

f At  beginning  of  coupling  time  delay,  failure  minimum  path  table 

becomes  active 


TOW  BY  SERVICE  VEHICLE 

t Calculate  travel  time  along  path  and  apply  speed  degradation  factor 

• Check  if  path  is  clear 

• Close  links  and  stations  merging  into  tow  path 

0 If  on-line  station  is  on  path,  preserve  one  and  only  one  path  through 
station 

• When  path  clear,  schedule  restart 
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TABLE  3-2.  OTHER  VEHICLE  RESPONSES  (BY  ROUTE) 


• Continue  revenue  service 
- No  action 


• Deboard  only  mode 

- Vehicles  marked  as  deboard  only  at  detection  time 

- Board  event  bypassed 

- Vehicle  unmarked  at  restart  time 


t Empty  circulation  mode 

- Vehicles  marked  as  empty  circulation  at  detection  time 

- All  passengers  deboard  at  first  station  stop 

- Board  event  bypassed 

- Vehicles  bypass  subsequent  station  stops 

- Vehicles  unmarked  at  restart  time 


f Wait  in  station  mode 

- Vehicles  marked  to  wait  in  station  at  detection  time 

- Vehicles  wait  prior  to  board  event 

- At  restart  time,  vehicles  unmarked  and  prompted  to  perform  board 
event 
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3.2  DESM  MODEL  VALIDATION 


The  objective  of  the  DESM  Model  Validation  task  was  to  ascertain  the 
degree  of  credibility  the  user  may  place  upon  model  generated  data  and 
statistics  in  light  of  the  assumptions  and  modeling  simplifications  that 
have  been  designed  into  the  DESM.  In  particular,  this  validation  effort 
addressed  the  means  by  which  vehicle  travel  on  a guideway  link  and  the 
merging  of  two  vehicles  from  separate  guideway  links  onto  a single  link  are 
modeled  and  if  these  modeling  techniques  in  any  way  adversely  affect  the 
credibility  and  usefulness  of  the  DESM  output  information.  The  question  of 
model  validity  that  was  addressed  was  the  fact  that  the  DESM  models  vehicle 
travel  across  a guideway  link  as  a series  of  discrete  events  when,  in  fact, 
vehicle  travel  is  in  practice  a continuous  process. 

The  general  methodology  applied  to  the  DESM  validation  was  as  diagrammed 
i n Fi gure  3-1 . 

The  general  procedure  followed  in  the  validation  task  was  to  compare 

vehicle  flow  through  a merge  junction  as  modeled  by  the  DESM  to  that  as 
modeled  by  the  Detailed  Operational  Control  Model  (DOCM).  The  DOCM  is  a 
continuous  model  completely  independent  from  the  DESM  and  developed  as  part 
of  the  System  Operations  Studies  program  specifically  for  the  purpose  of 
investigating  the  detailed  dynamics  of  vehicles  traveling  on  guideway  links 
and  merging  at  intersections. 

The  premise  was  made  that  if  the  DESM  and  DOCM  vehicle  travel  data 

through  the  intersection  compared  favorably  with  regard  to  (1)  travel  time 
through  the  junction  and  (2)  the  sequence  in  which  vehicles  effect  the 

merge,  then  the  modeling  approach  taken  within  the  DESM  as  well  as  any 

simplifications  or  assumptions  built  into  the  merge  algorithms  do  not 

detract  from  the  overall  confidence  that  the  model  user  can  have  in  the  DESM 

output  data.  The  general  process  used  to  make  the  comparison  of  travel 

times  and  merge  sequences  between  the  DESM  and  DOCM  was  as  outlined  in 

Figure  3-2. 
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It  was  concluded  from  the  results  of  the  validation  test  case  experi- 
ments performed  that  the  DESfi  models  the  process  of  vehicle  travel  in  the 
vicinity  of  guideway  merge  junctions  in  sufficient  detail  and  with  suffi- 
cient accuracy  that  for  vehicle  flow  densities  below  70  percent  of  the 
junction's  theoretical  capacity  no  compensation  is  required.  At  higher 
density  levels,  the  basic  DESM  modeling  approach  degrades.  This  degradation 
can,  however,  be  adequately  compensated  through  the  use  of  the  heuristic 
merge  table  which  was  designed  into  the  DESM. 


3.3  TIMEOUT/GROUP  DEMAND  RESPONSIVE  SERVICE  VALIDATION 


The  objective  of  the  Timeout/Group  Demand  Responsive  Service  Validation 
task  was  to  demonstrate  that  the  DESM  could  be  used  to  model  a service  mode 
operation  similar  to  that  in  use  at  the  Morgantown,  West  Virginia  PRT 
installation,  and  to  validate  the  DESM  using  actual  operation  data. 

Preliminary  effort  toward  this  objective  was  accomplished  by  developing 
the  appropriate  DESM  input  files  to  model  a specific  two-hour  period  of 
operation  at  Morgantown  PRT  and  then  by  executing  the  model  using  these 
files.  The  resulting  DESM  output  regarding  vehicle  dispatch  times  was  then 
compared  to  actual  vehicle  dispatch  times  for  the  correspondi ng  time  period 
at  Morgantown. 

The  results  of  this  comparison  indicate  that  to  the  extent  that  data  was 
available  for  actual  system  operation,  the  DESM  as  modified  can  accurately 
duplicate  the  vehicle  dispatch  process  as  seen  at  Morgantown  PRT. 
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4.0  ANALYSIS  PROCEDURE 


The  analysis  procedure  task  developed  an  analysis  approach  for  the 
design  of  ACT  systems  wherein  the  combinations  of  parameter  values  which  can 
influence  the  design  and  for  which  tradeoff  analyses  need  be  performed  are 
grouped  into  three  basic  categories.  The  three  categories  of  analyses 
relate  to  different  levels  of  design  specification.  The  consideration  of 
parameters  within  each  of  the  three  categories  corresponds  to  a separate 
phase  of  analysis  of  AGT  system  deployments.  The  three  phases  of  analysis 
which  are  described  in  the  procedure  are  initial  system  definition  and 
screening,  trade-off  analyses,  and  sensitivity  analyses.  The  initial  system 
definition  specifies  the  basic  system  parameters  which  define  alterntive 
system  concepts.  The  trade-off  analyses  considers  the  evaluation  of  other 
system  parameters  which  represent  major  alternatives  within  a given  system 
concept.  The  sensitivity  analyses  discusses  the  evaluation  of  the  system 
level  impacts  of  variations  in  still  other  system  parameters. 

The  initial  system  definition  phase  of  the  analysis  identifies  deploy- 
ment alternatives  which  merit  further  analysis.  Deployment  alternatives  are 
defined  in  terms  of  basic  parameters  such  as  vehicle  class  (Personal  Rapid 
Transit  (PRT),  Small  Vehicle  Group  Rapid  Transit  (SGRT),  etc.),  service 
policy,  and  network  configuration.  A deployment  alternatives  screening 
procedure  is  described  to  limit  the  number  of  different  deployments  to  be 
analyzed  in  subsequent  analyses. 

The  initial  system  definition  analysis  establishes  an  approach  to 
defining  application  areas,  demand,  networks,  and  routing  strategies  for 
scheduled  service.  Where  a specific  application  of  AGT  technology  is  to  be 
evaluated,  the  required  data  for  representation  of  site-specific  details  of 
the  application  area  is  discussed.  The  procedures  that  were  followed  for 
the  Systems  Operations  Studies  to  select  and  define  representative  appli- 
cation areas  for  analysis  using  the  SOS  software,  to  define  and  model 
candidate  networks,  and  estimating  procedures  for  AGT  demand  using  the  SOS 
software  are  discussed. 
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The  second  major  area  covered  in  the  initial  system  definition  process 
was  the  analysis  of  major  subsystems  to  determine  characteri  sties  and 
relationships  necessary  to  support  the  system  analysis.  Guidelines  for  the 
definition  of  major  subsystems  and  data  and  equations  for  calculating 
characteri sties  of  AGT  vehicles  such  as  dimensions,  performance,  energy 
utilization,  and  noise  generation  are  presented.  Equations  for  calculating 
minimum  headway  and  a procedure  for  estimating  control  system  cost  para- 
meters are  also  presented.  Alternative  operational  control  strategies  which 
can  be  modeled  using  the  SOS  software  are  defined.  Guidelines  for  sizing  AGT 
stations,  derived  from  analysis  using  the  Detailed  Station  Model  (DSM)  and 
the  Discrete  Event  Simulation  Model  (DESM),  are  presented.  The  cost  model 
is  discussed  and  representati ve  cost  data  are  presented.  A procedure  for 
conducting  an  availability  analysis  including  the  generation  of  subsystem 
reliability  data,  the  selection  of  representati  ve  failure  events,  the 
evaluation  of  failure  consequences  using  the  DESM,  and  the  evaluation  of 
system  availability  using  the  System  Availability  Model  (SAfi)  is  presented. 

A procedure  for  quickly  evaluating  system  deployments,  the  final  step  in 
the  first  phase  of  the  analysis,  was  developed.  The  purpose  of  the  initial 
deployment  screening  is  to  limit  the  scope  of  subsequent  more  detailed 
analysis  by  eliminating  from  further  consideration  deployment  alternatives 
which  were  clearly  inferior. 

A second  category  of  system  design  parameters  to  be  analyzed  as  a part 
of  the  analysis  procedure  were  also  identified.  These  parameters  represent 
major  alternatives  within  a given  system  concept  and  include  empty  vehicle 
management  strategies  for  demand  responsive  service  and  the  number  of  cars 
per  train  by  route  for  scheduled  service.  The  effects  on  system  perfor- 
mance, cost,  and  demand  of  alternative  values  of  parameters  in  this  category 
were  evaluated  in  trade  studies.  The  output  of  this  phase  of  the  analysis 
is  to  provide  a set  of  system  deployments  which  satisfy  performance  require- 
ments in  a cost  effective  manner.  Thus,  the  systems  are  well  defined  in 
terms  of  their  performance,  cost,  and  availability  characteri sties.  Guide- 
lines for  conducting  system  trade-off  analyses  are  developed  in  the  proce- 
dure. 
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The  final  category  of  system  design  parameters  to  be  evaluated  as  a part 
of  the  analysis  procedure  consists  of  a relatively  large  number  of  para- 
meters which  are  amenable  to  independent  variation  within  a narrow  range  of 
values.  These  parameters,  which  include  cruise  speed,  dwell  time,  vehicle 
capacity,  and  unit  cost  values,  are  varied  parametrical ly  in  a sensitivity 
analysis  to  characterize  their  impacts  on  system  performance  and  costs.  The 
results  of  these  sensitivity  analyses  are  used  to  define  an  optimum  con- 
figuration for  each  of  the  system  deployments  under  investigation. 

Figure  4-1  illustrates  the  manner  in  which  the  SOS  processors  are  used 
to  support  the  analyses  in  the  analysis  procedure.  The  figure  shows  the 
general  flow  of  data  from  one  part  of  the  analysis  to  another.  Each  of  the 
three  stages  of  analysis  includes  some  or  all  of  the  analyses  depicted  in 
Fi  gure  4-1 . 

The  uses  of  the  SOS  software  in  support  of  the  analysis  procedures  were 
also  defined  under  this  task.  The  initial  system  definitions  begin  with 
demand  generation  and  subsystem  analysis.  After  a set  of  deployment  con- 

cepts are  identified,  the  Feeder  System  Model  (FSM)  is  used  to  generate 
station-to-station  demand  matrices  for  each  deployment.  Inputs  to  the  FSM 
include  zone-to-zone  origin-destination  demand  data,  a network  description 
in  terms  of  station  coordinates  relative  to  zone  centroid  locations,  feeder 
system  charcteri sties,  and  an  estimate  of  station-to-station  trip  time  for 
the  deployment  under  consideration.  The  Input  Processor  of  the  DESM  is  then 
used  to  generate  the  AGT  system  performance  estimate.  Before  this  data  is 
input  to  the  FSM,  the  analyst  must  add  to  each  entry  an  estimate  of  initial 
wait  time  at  the  AGT  stations.  The  output  of  the  FSM  includes  station-to- 
station  demand  matrices  for  all  demand  periods.  These  matrices  serve  as 

direct  inputs  to  the  Discrete  Event  Simulation  Model  (DESM). 

The  network  description  used  in  the  Feeder  System  Model  (FSM)  for  demand 
generation  can  be  converted  to  DESM  input  with  the  aid  of  the  Network  Build 
Module  (NBM).  This  interactive  graphics  program  accepts  station  location 
and  network  connectivity  data  and  produces  the  network  file  which  is  input 
directly  into  the  DESM. 


4-3 


4-4 


FIGURE  4-1.  USE  OF  AGTT-SOS  SOFTWARE  FOR  SYSTEM  ANALYSIS 


The  Detailed  Station  Model  (DSM)  is  used  in  the  subsystem  analysis  to 
investigate  flows  and  queues  of  both  vehicles  and  passengers  in  on-line  or 
off-line  stations. 

The  Detailed  Operational  Control  Model  (DOCM)  is  used  in  other  subsystem 
analyses  to  evaluate  minimum  headway  requirements  and  vehicle  control 
alternatives. 

The  results  of  the  subsystem  analyses  are  used  in  the  development  of 
system  data  for  input  to  the  DESM.  The  DESM  evaluates  perfonmance  measures 
which  are  used  in  screening  the  deployments  to  identify  the  ones  which  have 
potential  for  satisfying  system  goals  and  are  worthy  or  more  detailed 
analysis. 

In  the  trade-off  analysis,  the  DESM  is  used  to  determine  the  combina- 
tions of  vehicle  capacity,  train  consist,  and  operating  headway  which 
satisfy  the  wait  time  and  performance  goals  for  major  demand  periods  of  the 
service  day.  The  size  of  the  operating  vehicle  fleet  is  the  major  indepen- 
dent variable  in  the  process  of  matching  the  performance  of  each  deployment 
with  the  performance  goals.  The  system  configuration  which  satisfies  the 
performance  goals  at  approximately  minimum  cost  is  selected  as  the  nominal 
configuration  for  each  deployment.  System  costs  are  evaluated  using  the 
System  Cost  Model  (SCM).  In  addition  to  capital  and  variable  costs,  the  SCM 
also  evaluates  land  utilization,  energy  consumption,  and  air  pollution. 
Required  inputs  to  the  SCM  include  system  operating  characteri sties  based  on 
DESM  outputs,  standby  fleet  size  generated  by  the  System  Availability  Model 
(SAM),  and  system  description  and  unit  cost  information  supplied  by  the 
analyst.  Trade-offs  of  major  system  parameters  are  made  by  comparing 
performance  and  cost  measures  for  the  nominal  deployments.  In  this  way  the 
overall  system  effects  of  various  parameters  are  considered  in  each  trade- 
off. If  the  performance  of  the  nominal  system  is  significantly  different 
from  that  initially  estimated,  the  demand  generation  process  is  repeated 
using  the  best  available  estimates  of  system  performance.  Then,  using 
updated  demand  estimates,  system  sizing  and  performance  analyses  are 
repeated  to  define  nominal  system  characteri sties. 
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System  availability  analysis  involves  the  use  of  both  the  DESM  and  the 
System  Availability  Model  (SAfl)  to  evaluate  the  consequences  of  failures  on 
system  performance.  The  DESM  is  used  to  generate  vehicle  and  passenger 
delay  information  relating  to  various  failures.  A trip  log  (a  file  con- 
taining a record  for  every  completed  trip)  is  generated  by  the  DESM  and  used 
as  direct  input  to  the  SAM  to  evaluate  the  number  of  passengers  delayed  by 
individual  failures.  Output  statistics  generated  by  the  DESM  are  used  by 
the  analyst  to  calculate  vehicle  delay  data  and  system  operating  character- 
istics for  input  to  the  SAM.  The  SAM  also  requires  input  parameters  such  as 
failure  rates  and  mean  time  to  repair.  The  SAM  generates  measures  of  system 
availability  and  the  standby  fleet  size  required  to  achieve  those  values  of 
availabil ity. 

Sensitivity  data  can  be  generated  by  varying  the  values  of  input  para- 
meters for  each  processor  independently  or  the  combined  use  of  models  may  be 
required  when  performance,  cost,  and  availability  are  evaluated. 
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5.0  APPLICATION  OF  SOS  MODELS 


The  SOS  models  have  been  utilized  for  the  performance,  cost  and  avail- 
ability analysis  of  a broad  range  of  actual  and  potential  applications  of 
automated  guideway  transit.  These  analyses  have  considered,  various  system 
types  such  as,  personal  rapid  transit  (PRT),  group  rapid  transit  (GRT),  and 
automated  rail  transit  (ART);  varying  demand  levels,  and  a number  of  dif- 
ferent network  configurations.  Extensive  analysis  of  shuttle  loop  transit 
(SLT)  systems  have  also  been  accomplished  using  the  SOS  models.  Table  5-1 
provides  the  general  character! sties,  of  the  types  of  systems  that  have  been 
analyzed  and  the  actual  implemented  system  of  which  these  character! sties 
are  considered  to  be  representati ve.  Table  5-2  lists  the  types  of  applica- 

tion scenarios  that  served  as  the  basis  for  performing  the  analysis. 

In  addition  to  the  above  applications  of  the  software  within  the  SOS 
contract,  the  models  were  also  used  during  the  preliminary  engineering  phase 
of  the  Detroit  Downtown  People  Mover  project  to  provide  performance  and  cost 
comparisons  for  the  network  configurations  which  were  under  study  for 
implementation. 
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TABLE  5-1.  GENERALIZED  SYSTEM  CHARACTERISTICS 
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SGRT  - Small  Vehicle  GRT 

IGRT  - Inlermediate  Vehicle  GRT 

LGRT  - Large  Vehicle  GRT 

ART  - Automated  Rail  Transit 


TABLE  5-2.  TYPES  OF  APPLICATION  SCENARIOS 
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6.0  POTENTIAL  APPLICATION  OF  SOS  MODELS  TO  CONVENTIONAL  TRANSIT 


The  SOS  and  Extended  SOS  work  was  entirely  concerned  with  the  modeling 
and  evaluation  of  automated  transit  systems.  However,  the  software  and 
techniques  developed  are  sufficiently  general  that  they  should  be  applicable 
to  most  forms  of  conventional  transit  as  well.  The  main  constraint  on  the 
use  of  the  simulation  software  is  that  vehicles  within  the  model  move  over 
fixed  pathways.  This  need  not  be  construed  to  mean  that  only  fixed  guideway 
systems  such  as  light  rail  can  be  modeled.  A set  of  fixed  bus  routes  also 
fits  this  condition. 

The  other  modeling  software  does  not  deal  with  explicit  representations 
of  the  individual  elements  of  the  system  link  specific  route  paths  but 
rather  uses  more  parametric  representations  like  total  routes  miles,  average 
failure  rates  or  number  of  daily  operations,  etc.  Thus,  this  software 
should  be  directly  applicable  to  any  system  which  can  be  represented  by 
those  parameters. 


6.1  SUMMARY  OF  SOS  MODEL  CHARACTERISTICS 


6.1.1  DISCRETE  EVENT  SIMULATION  MODEL  (DESM) 

The  purpose  of  this  simulation  model  is  to  represent  the  operation  of  a 
transit  system  in  terms  of  vehicle  and  passenger  movements.  This 

representation  has  enough  detail  to  allow  the  observation  of  individual 
vehicles  and  passengers.  However,  it  is  efficient  enough  that  periods  of 
operation  long  enough  to  aggregate  dependable  statistics  can  be  simulated.  In 
general,  the  ratio  between  real  time  and  simulation  time  will  fall  between 
100:1  and  10:1  depending  on  the  size  of  the  fleet  and  number  of  passengers 
being  simulated.  (A  larger  fleet  with  many  passengers  implies  a slower 
si  mul ati on  . ) 
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To  model  a system  in  the  DESM  requires  three  sets  of  input  data. 


A representation  of  the  paths  available  to  vehicles  within  the 
system  in  terms  of  nodes  and  links  interconnecting  those  nodes. 
This  data  include  identification  and  detailed  configuration  of  nodes 
which  function  as  stations  or  passenger  access  points. 

A set  of  system  equipment  operating  characteri sties.  This  data 
includes  items  such  as  vehicle  capacities,  link  travel  speed  limits, 
dispatching  and  scheduling  constraints,  boarding  and  deboarding 
delay  functions,  and  a set  of  routes  defined  on  the  network. 

A matrix  of  the  passenger  demand  on  the  system  at  the  network 
stations.  The  demand  being  modeled  can  vary  with  time  both  in  overall 
magnitude  and  in  the  spatial  distribution  of  demand  among  the 
stati ons . 

In  general,  the  structure  of  the  system  network,  and  the  demand  being 
imposed  on  the  system  are  defined  in  input  data  files  rather  than  being 
designed  into  the  simulation.  A variety  of  policies  for  dispatching 
vehicles  and  maintaining  separations  between  them  is  available  within  the 
program.  The  size  of  the  system  which  can  be  simulated  is  limited  by 
practical  considerations  of  computer  memory  size  and  run  time  rather  than 
any  inherent  constraints  within  the  software.  For  convenience  in  performing 
trade-off  studies  such  as  evaluating  alternative  vehicle  sizes  and  route 
densities,  most  of  the  input  data  can  be  varied  at  runtime  without 
completely  redeveloping  input  files.  For  instance,  operating  speeds  on  some 
links  could  be  changed  to  study  the  impact  of  a large  construction  project 
on  the  operation  of  a bus  route  passing  through  the  affected  area. 

Application  of  the  DESM  to  any  system  using  fixed  guideways  with  a 
limited  number  of  stations  (e.g.,  a subway  system)  is  straight  forward.  The 
only  difference  being  the  need  for  representing  manual  rather  than  automatic 
operation.  For  rail  systems,  a block  system  for  maintaining  safe  vehicle 
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separations  is  normal  in  either  automatic  or  manual  operation  and  thus  at 
the  level  of  detail  used  in  the  DESM  there  is  no  real  distinction 
necessary. 

Light  rail  systems  operated  manually  can  have  quite  different  character- 
istics from  those  anticipated  in  automated  systems.  First,  these  systems 
usually  depend  on  the  operator  to  maintain  separation  particularly  when 
operated  at  grade  and  mixed  with  other  traffic.  Second,  stops  to  pickup  and 
discharge  passengers  can  be  very  frequent  and  these  stops,  at  least  super- 
ficially, do  not  resemble  formal  stations.  Finally,  when  operating  at  grade 
and  mixed  with  other  traffic,  operating  speeds  are  affected  by  a variety  of 
extraneous  factors  like  other  traffic  and  traffic  controls.  These  charac- 
teristics require  some  ingenuity  to  model  since  they  are  not  directly 
represented  within  the  DESM.  Human  maintenance  of  vehicle  separation's 
resembles  the  operation  of  a vehicle  follower  control  system  which  is  an 
option  in  the  DESM.  Individual  performance  varies  far  more  than  with 
automatic  controls,  but  for  a relatively  large  sample  these  differences 
should  not  significantly  degrade  the  overall  system  statistics  developed. 
The  representation  of  individual  stops  as  stations  is  quite  possible  but 
depending  on  the  system  size  may  prove  impractical.  One  possible 
alternative  which  may  be  considered  in  this  event  is  to  lump  several  stops 
into  one  node.  To  do  this  would  require  that  the  station  dwell  time  in  the 
lumped  node  and  the  travel  time  over  the  links  connecting  those  nodes  be 
made  artificially  large  so  that  the  resulting  travel  from  one  node  to  the 
next  would  be  sufficiently  accurate  for  statistical  purposes.  This  lumping 
of  access  nodes  will  also  make  the  demand  matrix  more  tractable  in  size. 
Since  delays  in  boarding  and  deboarding  can  be  made  a function  of  the  total 
number  of  passengers  involved,  no  artificial  manipulation  of  this  portion  of 
station  dwell  time  need  be  performed. 

The  modeling  of  travel  speed  in  a mixed  traffic  at  grade  system  is  a 
more  complex  problem.  If  the  purpose  of  a study  is  to  observe  detailed 
interactions  of  the  system  vehicles  with  infringing  traffic,  and  traffic 
controls  no  good  modeling  mechanism  exists  within  the  DESM.  However,  if  the 
purpose  is  to  evaluate  the  system  wide  effects  of  constricted  through  put  on 
links,  then  it  is  likely  that  assigning  low  speeds  to  the  links  involved  will 
be  adequate.  Or,  more  accurately,  the  effect  of  the  infringing  traffic  on 
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transit  vehicle  performance  may  be  modeled  by  introducing  standard  deviations 
to  individual  link  speeds.  Use  of  the  DESM  at  this  detailed  level  may  be 
included  as  an  added  option  to  the  model. 

If  the  effects  of  traffic  quantization  by  stop  lights  is  of  interest,  a 
limited  model  of  this  might  be  achieved  by  establishing  nodes  at  the  traffic 
lights  and  superimposing  the  traffic  light  timing  pattern  on  the  headway  zone 
as  an  optionally  added  processing.  Use  of  the  DESM  at  this  detailed  level  of 
modeling  is  recommended  only  if  it  is  suspected  that  effects  such  as  these  are 
having  large  consequences  over  all.  Modeling  in  terms  of  low  average  speeds 
across  links  should  generally  be  sufficient  to  develop  reliable  statistics  on 
system  operation  or,  more  importantly,  changes  in  those  statistics  due  to 
changes  in  either  operating  policies  or  road  conditions. 

Bus  systems  introduce  another  variation  from  the  design  purpose  of  the 
DESM  in  that  they  apparently  do  not  utilize  a fixed  guideway.  However,  for 
modeling  purposes,  the  route  structure  of  a bus  system  is  equivalent  to  the 
network  of  a fixed  guideway  system.  One  could  view  a city  street  map  as  the 
network  but  this  would  be  unnecessarily  complex  since  only  those  streets 
actually  used  by  the  buses  are  needed.  If,  however,  it  is  known  a priori 
that  certain  alternative  streets  are  likely  to  be  considered  as  alternatives 
these  could  be  entered  for  later  convenience  since  it  is  not  necessary  that 
every  network  link  be  used  by  a route  structure  under  consideration. 

Once  the  basic  network  has  been  defined,  a bus  system  has  most  of  the 
characteri sties  discussed  previously  for  light  rail  at  grade  mixed  traffic 
modeling.  The  main  new  item  to  be  considered  is  the  ability  of  busses  to 
pass  one  another  as  a normal  operating  procedure.  To  model  this  capability, 
it  will  be  necessary  to  introduce  artificial  redundant  bypass  links  at 
points  in  the  route  structure  where  this  will  happen  in  normal  operation. 
Another  method  v/ould  be  to  model  stops  as  off-line  stations  so  that  busses 
can  pass  through  without  stopping  if  desired.  For  most  normal  operations 
this  should  not  pose  any  great  limitations  on  the  accuracy  of  the  results  of 
a simulation.  It  is  felt,  however,  that  using  the  DESM  for  modeling  bus 
breakdowns  in  operation  is  not  likely  to  be  effective,  where  for  fixed 
guideway  systems  this  is  a highly  useful  technique  since  one  stopped  vehicle 
can  propagate  stoppages  over  large  parts  of  a fixed  network  rather  quickly 
by  blocking  a heavily  used  link. 
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6.1.2  SYSTEM  AVAILABILITY  MODEL  (SAM) 


The  purpose  of  the  SAM  is  twofold.  Given  inputs  defining  equipment  and 
vehicle  failure  rates,  causal  factors,  failure  consequences  and  system 
operating  statistics,  the  SAM  estimates  system  availability  in  terms  of  the 
probability  that  the  average  passenger  will  complete  a trip  without  being 
delayed  more  than  some  threshold  value.  A secondar7  calculation  in  the  SAf-1 
estimates  the  number  of  spare  vehicles  required  to  ensure  that  a specific 
operating  fleet  size  will  be  available.  This  calculation  uses  data  on 
average  service  times,  number  of  available  maintenance  bays,  preventive 
maintenance  policy,  vehicle  failure  rates  and  system  operating  statistics  to 
calculate  the  needed  fleet  of  spares  over  a range  of  probabilities  that 
replacements  for  failed  vehicles  will  be  available. 

Since  the  representation  of  a system  in  this  model  is  parametric  rather 
than  explicit  it  is  relatively  independent  of  the  system  type.  What  is 
required  for  the  availability  computation  is  a table  of  failure  consequences 
(in  terms  of  passenger  delays)  for  areas  of  the  system  and  times  of  day 
generated  either  by  hand  or  through  use  of  the  DESM  and  a table  of  causative 
factors  (like  vehicle  operating  hours  or  miles  of  travel)  partition  in  a 
similar  manner.  The  fleet  size  computation  allows  the  number  of  available 
maintenance  bays  and  assumed  routing  maintenance  policy  to  be  easily  varied  so 
that  trade-off  studies  of  the  consequences  of  enlarging  maintenance  facilities 
can  be  performed. 


6.1.3  SYSTEM  COST  MODEL  (SCM) 

The  purpose  of  the  SCM  is  to  aggregate  system  costs  (both  capital  and 
operating)  in  a time  phased  manner  so  that  system  life  cycle  costs  can  be 
calculated.  The  system  representation  is  a set  of  three  tables  defining 
unit  costs,  quantities  of  units  making  up  the  system,  and  a set  of  general 
economic  factors  to  be  applied.  System  elements  can  be  defined  to  have 
varying  useful  lifetimes  and  associated  with  each  is  an  end  of  life  value. 
Again  since  the  representation  of  the  system  is  independent  of  the  type  of 
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control  system  or  operating  policy,  this  model  can  be  applied  to  any  system 
type.  To  provide  further  generalization  within  this  model,  it  has  been 
configured  as  an  interpretive  processor.  This  allows  the  set  of  equations 
processed  to  relate  unit  costs  and  quantities  and  to  perform  the  life  cycle 
and  economic  factor  calculations  to  themselves  be  an  input  file.  Thus,  it 
is  possible  to  completely  revise  the  calculations  in  this  model  within  very 
broad  limits  without  new  programming.  One  use  of  this  ability  which  has 
been  made  was  a study  of  the  trade-off  between  system  cost  and  reliability 
as  more  expensive  MIL  Spec  parts  were  substituted  for  commercial  grade  elec- 
tronics in  a control  system.  The  modifications  made  were  to  simultaneously 
aggregate  subsystem  failure  rates  and  costs  from  tables  of  part  cost, 
failure  rates,  and  part  utilization  in  the  subsystems.  The  set  of  equations 
existing  in  the  present  version  of  the  SCM  are  covered  in  detail  in  the  SOS 
"System  Cost  Model  User's  Manual"  (EP-78170). 

6.2  GENERAL  APPLICATION  APPROACHES 


Throughout  the  following  discussions,  it  will  be  assumed  that  a 
calibrated  demand  model  exists  on  the  area  under  study.  This  is  necessary 
for  any  investigations  of  usage  or  revenue  sensitivities  to  changes  in  route 
structure  or  service  level.  However,  if  this  is  not  the  case,  the  Feeder 
System  Model  (FSM)  within  the  SOS  software  can  be  used  to  provide  rough 
estimates  of  demand  sensitivities.  This  model  operates  on  a representation 
of  demand  which  is  distributed  geographical  ly  and  maps  it  onto  the  entry  and 
exit  points  of  a transit  network.  It  is  assumed  that  the  demand  is  all 
transit  oriented  in  that  it  will  use  the  transit  mode  if  at  all  reasonable. 
Thus,  it  gives  a relative  measure  of  the  demand  which  a particular  route 
structure  can  capture.  Level  of  service  is  factored  in  through  use  of  a 
diversion  curve  operating  on  the  total  travel  time  for  a trip  using  transit 
as  compared  to  that  for  an  assumed  alternate  mode.  Clearly,  the  accuracy  of 
the  absolute  results  are  highly  dependent  upon  the  basic  transit  oriented 
demand  representation  and  the  assumption  made  as  to  the  performance  of  the 
competing  modes.  However,  the  FSM  if  calibrated  to  current  system 
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performance  will  provide  useful  relative  data  on  alternative  system  de- 
ployments. That  is,  it  can  indicate  whether  demand  capture  is  likely  to 
increase  or  decrease  in  response  to  changes  in  a transit  system. 


6.2.1  OPERATIONS  PLANNING 

To  apply  the  SOS  software  operations  planning  or  alternatives  evalu- 
ations for  a property,  the  major  preliminary  effort  will  be  the  development 
of  a data  base  representing  the  system  network.  For  a rail,  or  other  fixed 
guideway  system  this  can  be  a relatively  straight  forward  node  and  link 
representation  of  the  various  guideway  segments.  As  discussed  under  the 
DESM  summary,  systems  with  many  stops  for  passengers  rather  than  more  widely 
spaced  stations  will  require  that  trade-offs  between  model  fidelity  and 
computer  usage  be  made.  The  number  of  points  at  which  passengers  can  enter 
or  leave  the  system  will  affect  not  only  the  network  storage  size  but  the 
size  of  the  demand  matrix  to  be  developed.  Since  demand  is  represented  in 
an  0/D  matrix,  storage  and  processing  time  for  demand  varies  as  the  square 
of  the  number  of  access  points.  This  consideration  leads  to  the  suggestion 
that  the  system  network  be  represented  where  practical  as  a set  of  psuedo 
station  nodes  each  of  which  is  either  a route  stop  or  an  aggregate  of  a few. 
Areas  of  particular  sensitivity  or  interest  like  a CBD  could  be  modeled  in 
detail  while  the  remainder  of  the  network  data  base  might  well  evolve  into  a 
lumped  node  representat i on  of  the  entire  network  and  a set  of  detailed 
subnetworks  which  could  be  substituted  for  one  or  more  psuedo  nodes  as  desired 
for  a particular  analysis. 

In  parallel  with  the  network  data  base,  a calibrated  demand  model  of  the 
metropolitan  area  of  interest  should  be  established.  It  would  be  desirable 
from  an  analytic  point  of  view  for  this  model  to  be  maintained,  recalibrated 
and  updated  on  a regular  basis,  perhaps  on  an  annual  or  bi-annual  basis. 
This  model  will  be  used  iteratively  with  the  system  performance  simulation 
to  establish  projected  usages  for  alternatives  being  considered.  At 
present,  SOS  does  not  have  a method  for  projecting  revenues  so  some  esti- 
mating method  should  be  developed  which  can  take  demand  estimates  and 
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derive  revenue  estimates.  This  could  be  accomplished  with  the  SCM  with  some 
minor  modifications. 

Another  data  set  which  is  required  is  the  cost  model  input  tables  of 
unit  costs,  system  definition,  and  economic  factors.  The  SCM  is  suffi- 
ciently general  in  its  present  configuration  that  most  cases  should  be 
covered  by  a redefinition  of  variables.  However,  a property  might  find  it  a 
useful  task  to  develop  an  equation  definition  file  specific  to  that  property 
to  be  included  in  the  cost  model  portion  of  the  data  base. 

Finally,  a file  will  be  developed  defining  the  system  characteri sties . 
These  include  route  definitions,  operating  speeds,  vehicle  sizes  and  a set  of 
operating  policies  covering  the  number  of  vehicles  per  route,  train  consists, 
and  schedule  and  dispatching  policies.  The  data  in  this  file  will  be  the  most 
commonly  varied  to  test  operational  methods. 

The  final  step  in  setting  up  the  models  should  be  a validation  run 
against  some  standard  set  of  data  covering  one  or  more  hours  of  manual 
operations.  This  run  serves  a dual  purpose.  First,  it  will  establish 

confidence  in  the  model  performance  and  second  it  will  provide  a base  line 
for  future  evaluations  of  alternatives. 

The  process  which  can  be  used  to  evaluate  changes  in  system  operations 
is  straight  forward.  First  the  data  base  files  are  called  up  and  modified 
to  include  the  desired  changes.  In  the  case  of  system  data  these  changes 
can  be  made  at  run  time.  For  network  alterations,  some  prior  manipulation 
using  the  SOS  graphic  support  software  may  be  needed  to  develop  new  networks 
and  route  data  files.  When  the  model  of  the  altered  system  is  ready,  it  is 
simulated  using  the  DESM.  This  generates  the  needed  data  for  input  to  the 
SCM,  demand,  and  revenue  models.  If  the  changes  result  in  significant 
changes  in  demand,  the  DESM  run  should  be  repeated  using  the  new  demand 
matrix  to  test  for  significant  changes  in  level  of  service  which  might 
affect  the  demand  model.  This  iteration  of  simulation  and  demand  models 
should  lead  to  a state  of  equilibrium  at  which  time  new  costs  can  be 
generated  in  the  SCM  and  final  evaluation  of  the  operating  policy  being 
tested  can  be  made. 
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6.2.2  MIXED  MODE  OPERATION  EVALUATION 


An  illustrative  scenario  for  the  use  of  SOS  techniques  is  a situation 
similar  to  the  Miami  case  with  a rail  rapid  transit  (RRT)  line  feeding  a CBD 
circulator.  The  character! sties  of  the  RRT  are  essentially  fixed  with  the 
major  variable  being  the  frequency  and  loading  of  arriving  trains  at  the 
interface  stations.  The  CBD  circulator  is  assumed  to  be  a guideway  system 
using  small  vehicles  at  relatively  close  headways.  The  purpose  of  the 
investigation  is  to  determine  the  appropriate  circulator  fleet  size  and 
scheduling  to  optimize  the  total  system  performance  and  to  identify 
potential  for  the  sectors  including  demand  levels  at  which  system  perfor- 
mance starts  to  degrade. 

This  evaluation  needs  the  same  initial  data  base  identified  in  the 
preceding  section  in  operations  planning.  However,  in  this  case  the 
representation  of  demand  at  the  DESM  input  will  be  held  constant  and  the 
level  of  service  optimized  to  handle  that  demand.  In  the  last  stages  of  the 
study,  overall  demand  magnitude  can  be  varied  by  changing  one  variable  to 
test  the  sensitivity  of  the  final  design  to  demands  beyond  the  design 
poi nt. 

Scheduling  and  fleet  size  variations  can  be  handled  by  changing  a few 
input  variables  to  the  DESM  and  resimulating.  The  technique  recommended  is 
to  establish  a nominal  configuration  in  the  DESM  and  SOM  input  files  and 
developing  a base  set  of  operating  statistics  and  costs  for  that  case. 
Changes  can  then  be  made  in  variables  defining  fleet  size,  scheduling, 
operating  policies,  vehicle  sizes  and  demand  magnitude  or  any  other  system 
characteristic  and  rerun  made  to  establish  performance  and  cost  sensitivi- 
ties to  the  parameters.  In  general  these  changes  require  only  that  new 
values  for  the  selected  variables  be  supplied  at  runtime  initil ization  with 
the  input  processor  handling  the  conversion  of  those  values  into  the  form 
needed  by  the  simulation  automatically. 
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Once  the  trends  of  the  various  operating  statistics  have  been  esta- 
blished, those  changes  which  result  in  improvements  can  be  pursued  to  the 
point  of  diminishing  returns.  To  do  this  effectively,  the  SCM  should  be 
rerun  for  each  new  system  configuration  so  that  any  performance  improvements 
achieved  can  be  evaluated  for  cost  effectiveness. 

A final  step  in  this  study  would  probably  be  to  configure  a conventional 
bus  circulation  system  in  place  of  the  fixed  guideway  system  and  compare 
performance  and  costs  between  the  two.  If  desired,  the  same  optimization 
process  can  be  applied  to  this  alternative  system  configuration  before 
making  comparisons. 


6.2.3  MAINTENANCE  FACILITIES  PLANNING 

The  SOS  System  Availability  Model  (SAM)  has  two  major  functions.  The 
first  is  to  calculate  the  performance  reliability  of  a system  as  perceived 
by  an  average  user  in  terms  of  his  probability  of  completing  a trip  with  no 
failure  induced  delays.  The  second  is  to  calculate  the  standby  fleet  size 
needed.  This  latter  calculation  considers  average  vehicle  failure  rates, 
nominal  peak  period  operating  statistics,  preventive  maintenance  practices, 
average  vehicle  repair  rates,  the  number  of  repair  bays  available  and  the 
desired  operation  fleet  size.  From  this  data,  a table  showing  the  expected 
number  of  vehicles  under  repair  and  the  needed  standby  fleet  for  a user 
selected  range  of  probabilities  that  a replacement  vehicle  will  be  available 
when  an  operating  vehicle  fails. 

Each  of  these  input  variables  can  be  changed  independently.  By  using 
the  SCM  (an  SCM  modification  or  a separate  calculation),  many  questions  on 

the  sizing  of  maintenance  facilities  and  the  desirability  of  changing 

routine  maintenance  policies  can  be  investigated.  One  can  compare  the 

capital  investment  in  facilities  needed  to  improve  meantime  to  repair 
performance  against  the  additional  cost  of  standby  vehicles  for  the  same 
improvement  in  replacement  vehicle  availability.  Given  an  estimate  of 

failure  rate  decrease  due  to  more  preventive  maintenance  one  can  trade-off 
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such  policy  changes  against  fleet  or  facilities  enlargement.  If  failure 
rate  improvements  can  be  achieved  by  use  of  higher  cost  parts,  the  cost 
effectiveness  of  the  approach  can  be  tested. 

The  data  base  needed  for  this  use  of  the  SOS  techniques  includes  the 
previously  discussed  SCM  input  data,  average  vehicle  failure  rates,  average 
vehicle  repair  times,  frequency  and  duration  of  scheduled  maintenance,  and 
statistics  on  normal  operations  in  terms  of  average  vehicle  mileage  or 
operating  hours  per  unit  time,  etc. 


6.2.4  PERFORMANCE  COMPARISONS 

An  interesting  application  of  the  SOS  techniques  which  is  a variation  of 
the  mixed  mode  study  discussed  in  paragraph  6.2.2  is  the  comparison  of 

automated  and  manual  operation  of  the  same  fixed  guideway  facility.  The 
same  approach  of  establishing  a baseline  configuration  and  evaluating  its 

performance  cost  and  availability  keeping  some  normal  demand  representation 
as  a fixed  input  can  be  used. 

The  major  modeling  differences  between  manual  and  automatic  control  lies 
in  the  selection  of  a policy  to  maintain  vehicle  separation  around  a route 
in  the  automatic  case.  It  may  also  be  necessary  to  tailor  the  control 

policy  if  a specific  automated  system  is  to  be  modeled.  To  assure  a 

meaningful  comparison,  cost  differences  (both  capital  and  operating)  and 

reliability  differences  must  be  fully  defined.  These  differences  include 

the  obvious  elimination  of  the  operating  crew  and  the  addition  of  control 

equipment  as  well  as  changes  in  such  things  as  maintenance  crew  size 
requirements  and  average  elapsed  time  before  recovery  of  a failed  vehicle. 

In  all  such  comparisons,  it  is  vital  that  as  many  variables  as  possible 
held  constant  between  systems  so  that  differences  in  performance  can  be 

attributed  to  the  system  characteri sties  rather  than  extraneous  items.  It 
is  for  this  reason  that  it  is  recommended  that  an  identical  trip  list  be 
used  as  input  to  all  runs  to  minimize  performance  differences  due  to  random 
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changes  in  passenger  arrival  times,  etc.  An  extension  of  this  reasoning 
would  suggest  that  both  systems  being  compared  be  independently  optimized 
before  comparisons  are  made  since  techniques  which  work  effectively  for  one 
system  type  many  not  be  applicable  to  the  other. 
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7.0  SUMMARY 


The  XSOS  program  consisted  of  the  following  eight  (8)  tasks: 

Task  1 - New  Scenario  Analysis 
Task  2 - Analysis  Procedure 
Task  3 - Software  Update 
Task  4 - Workshops 

Task  5 - Failure  Management  Modifications 
Task  6 - DPM  Implementation  Report 
Task  7 - Technical  Reviews  and  Final  Report 
Task  8 - Universal  Service  Strategy  • 

Task  1 consisted  of  two  validation  efforts,  1)  the  validation  of  the 
merge  modeling  accuracy  of  the  DESM,  and  2)  the  replication  of  the 
dispatching  character! sties  of  a Morgantown  type  system  using  the  DESM  for  the 
purposes  of  testing  the  models  generality  and  validating  the  model  against 
actual  operational  data.  These  efforts  were  concluded  with  the  issuance  of 
the  DESM  Validation  Final  Report  No.  EP-81055  and  the  Timeout/Group  Demand 
Responsive  Service  Algorithm  Validation  Report  04-1-810011. 

The  Analysis  Procedure,  Task  2,  included  the  development  of  a procedure 
for  analyzing  AGT  systems  using  the  SOS  developed  models,  a Memo  Report  on 
the  Evaluation  of  UMTA  Service  Dependability  Measures  and  a Memo  Report  on 
the  Limitations  of  the  SPM.  Task  2 was  completed  with  the  issuance  of 
Procedure  For  The  Analysis  of  Representative  AGT  Deployments,  Report  No. 
GP-80071 , Evaluation  of  UMTA  Service  Dependability  Measures  Using  SOS 
Softvvare,  Memo  Report  S0S-F-800036,  and  Memo  Report,  Use  And  Limitations  Of 
The  SOS  System  Planning  Model  (SPM),  J.  Thompson  to  A.  Priver,  dated  August 
14,  1980. 

The  development  and  delivery  of  the  code  and  updated  DESM  User's  and 
Programmer's  Manuals  to  include  the  DOT-TSC  required  changes  to  the  DESM  and 
the  Failure  Management  and  Morgantown  Modifications  was  accomplished  in 
fulfillment  of  Task  3.  The  code  was  supplied  in  the  form  of  a magnetic  tape 
containing  the  latest  version  of  the  DESM.  The  DESM/DPMS  modifications 
developed  at  DOT-TSC  and  implemented  by  GM-TSC  are  documented  in  Memo  Report 
S0S-F-800057.  The  User's  Manual  was  updated  to  describe  the  new  functions. 
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define  the  core  requi rements,  and  describe  the  new  input  and  output  func- 
tions. Operating  procedures  were  updated,  new  error  messages  added,  new 
routines  included  and  output  reports  revised  to  reflect  the  modification 
made  to  the  user's  manual.  The  Programmer's  Manual  update  included  the  core 
memory  requirements  and  revision  of  the  code  segment  tables  to  include  the 
new  members.  The  new  global  variables  were  included  as  were  new  debug 
flags.  The  logic  tables  were  revised,  new  routines  added  and  old  routines 
updated.  The  update  of  these  two  manuals  was  provided  in  the  form  of  a set 
of  revision  pages  for  each  manual. 

Task  4 consists  of  the  GM-TSC  participation  in  two  workshops  on  the 
capabilities  and  applications  of  the  SOS  models  and  the  accomplishments  of 
the  XSOS  program.  Support  of  and  participation  in  Workshop  I was  accom- 

plished in  December,  1979.  The  completion  of  the  remainder  of  this  task 
will  occur  in  September,  1981  with  the  GM-TSC  participation  in  the  APTA 
Committee  Meeting  on  System  Operations  Studies  Technology.  Here,  presenta- 
tions will  be  given  on  the  Analysis  Procedure  (Task  2)  and  the  Application 
of  the  SOS  models  to  conventional  transit. 

The  documentation  of  the  Failure  Management  Modifications  was  accom- 
plished under  Task  5.  Three  memos  were  published  which  describe  the  func- 

tional and  technical  requirements  of  the  software  modifications.  These 
include  memos  on  the  implementation  of  an  enhanced  failure  management 
capability,  scheduled  service  vehicle  spacing  algorithm,  and  scheduled 
service  active  fleet  size  management.  The  documentation  was  provided  as  an 
attachment  to  the  memo  dated  10  October  1980  from  R.A.  Lee  to  Dr.  Arthur  S. 
Pri  ver. 

The  installation  of  the  DPMS  software  at  APL  in  January,  1980  along  with 
the  software  documentation  fulfilled  the  requirements  of  Task  6. 

Task  7 consisted  of  five  (5)  technical  reviews  presented  by  GM-TSC  on 
the  financial  and  technical  status  of  the  XSOS  program.  A presentation 
overview,  results,  conclusion  and  action  items  were  documented  for  each 
technical  review  and  provided  in  memo  form  to  DOT-TSC  along  with  copies  of 
all  materials  presented.  This  final  report  concludes  the  remaining  effort 
to  be  accomplished  under  this  task. 
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Two  efforts  were  included  within  the  scope  of  Task  8.  These  consisted 
of,  1)  the  software  design  and  documentation  necessary  to  enable  a 
programmer  to  implement  the  universal  service  strategy  concept  described  in, 
"Proposal  for  Implementation  of  Universal  Service  Strategy  Simulation 
Software",  EP-80002  into  the  DESM  software,  and  2)  the  development  of 
examples  of  conventional  transit  applications  where  the  system  level  models 
(DESM,  SCM  and  SAM)  developed  during  the  SOS/XSOS  programs,  could  be  used  to 
study  and/or  investigate  performance  cost  and  availability  trade-offs.  The 
software  design  and  documentation  effort  was  accomplished  through  a two  (2) 
day  technology  transfer  meeting  held  at  GM-TSC  with  DOT-TSC  personnel  on 
July  28  and  29,  1981.  The  application  of  the  SOS  models  to  conventional 
transit  effort  will  be  completed  with  the  presentation  of  results  at  the 
APTA  Coimittee  Meeting  on  System  Operations  Studies  Technology. 
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APPENDIX 


REPORT  OF  NEW  TECHNOLOGY 

The  work  performed  under  this  contract,  while  not  expected  to  lead  to 
any  new  invention,  has  led  to  the  development  of  several  computer  models  and 
an  analysis  procedure  for  evaluating  the  guideway  transit  system  operations 
using  these  models.  The  models  and  the  analysis  procedure  may  be  and  have 
been  used  for  the  transit  analysts  to  understand  the  impact  of  transit  opera- 
tions on  transit  performance  so  as  to  improve  the  transit  productivity  and 
operational  efficiency. 
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